home *** CD-ROM | disk | FTP | other *** search
Wrap
Text File | 1996-03-23 | 112.7 KB | 3,302 lines | [ TEXT/R*ch]
C.S.M.P. Digest Wed, 06 Mar 96 Volume 3 : Issue 139 Today's Topics: Bizarre trap patching problem FastRandom() source Hi ho, Hi ho, STR#ing we will go. How do I switch printers without the Chooser? On obtaining rowBytes... (Was Re: Video Memory Access) PEF (Preferred Executable Format) Info Needed Reconnecting Mounted Appleshare Volumes Stuck in a bottleneck USENET Macintosh Programming Awards (UMPA) [Q] NURBs and lighting pragma once vs #ifndef The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and csmp.games. It is designed for people who read news semi-regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. ------------------------------------------------------- >From nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) Subject: Bizarre trap patching problem Date: 13 Feb 1996 01:16:02 GMT Organization: Dept. of Information Science, University of Otago This is weird -- I've written a patch to _Control (still working on this MacTCP sending stuff), and it works fine... on 68k machines. If I install it on my LC at home, the patch is activated fine and does what it's supposed to. If I install it on my 6100 at work, the patch is again activated fine and does what it's supposed to. _However_, after the patch has finished executing, at some point I've been unable to determine tha machine crashes with an illegal instruction. This occurs at a location in low memory (somewhere around $70!), so I'm guessing that somewhere in there is a jump to NIL. The bit that's got me though is that this happens _after_ the patch has finished executing and returned (I know this for a fact, I stepped through it in MacsBug). How _long_ after is anyone's guess. The only difference I can think of is that the patch in both cases is being activated from Eudora, which is fat. When I run it at home, the patch is called from 68k code. When I run it at work, it's called from PPC code. Note that _Control gets called a lot by the OS without any hiccups on both architectures. Is there something I should be doing that I'm not aware of? I do know that _Control is called at interrupt time, but I'm not aware of anything I do that's dangerous in that respect; does that even matter in the PPC environment anyway? I suppose it does, given that I'm patching a 68k trap with 68k code. But then, why does it crash on the PPC and not the 68k? Weird. My code looks something roughly like this (CW8, BTW, and excuse any typos): typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0; ControlProcPtr gOldTrap; #pragma parameter __D0 main(__A0) OSErr main(ParmBlkPtr pb); OSErr main(ParmBlkPtr pb:__A0):__D0 { TCPiopb *tcpPB = (TCPiopb)pb; if (pb->csCode == TCPSend) { // I can't remember the exact code here, but it goes something like this: // get stream ptr from tcpPB and stuff it into a TCPStatus PB if (PBControlSync(statusPB) == noErr) { if (statusPB.remotePort == 25) [SMTP] { // wdsEntry *theWDS = the WDS from tcpPB ; while (theWDS->length) { //if (theWDS->ptr == pattern) // beep (will eventually do things to WDS contents) else theWDS++; } } } gOldTrap(pb); } I might have to dig up the real code and post it. Anyway, can anyone see anything obviously dangerous in the above? ===================================================================== Nigel Stanger, Internet: nigel.stanger@stonebow.otago.ac.nz University of Otago, Phone: +64 3 479-8179 Dunedin, NEW ZEALAND. Fax: +64 3 479-8311 +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Tue, 13 Feb 1996 16:51:53 +1300 Organization: HyperMedia Unit, Comp Sci, Auckland University In article <nigel.stanger-1302961418000001@ou176027.otago.ac.nz>, nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) wrote: >This is weird -- I've written a patch to _Control (still working on this >MacTCP sending stuff), and it works fine... on 68k machines. If I install >it on my LC at home, the patch is activated fine and does what it's >supposed to. If I install it on my 6100 at work, the patch is again >activated fine and does what it's supposed to. _However_, after the patch >has finished executing, at some point I've been unable to determine tha >machine crashes with an illegal instruction. This occurs at a location in >low memory (somewhere around $70!), so I'm guessing that somewhere in >there is a jump to NIL. > >The bit that's got me though is that this happens _after_ the patch has >finished executing and returned (I know this for a fact, I stepped through >it in MacsBug). How _long_ after is anyone's guess. > >The only difference I can think of is that the patch in both cases is >being activated from Eudora, which is fat. When I run it at home, the >patch is called from 68k code. When I run it at work, it's called from PPC >code. Note that _Control gets called a lot by the OS without any hiccups >on both architectures. Is there something I should be doing that I'm not >aware of? > >I do know that _Control is called at interrupt time, but I'm not aware of >anything I do that's dangerous in that respect; does that even matter in >the PPC environment anyway? I suppose it does, given that I'm patching a >68k trap with 68k code. But then, why does it crash on the PPC and not the >68k? Weird. > >My code looks something roughly like this (CW8, BTW, and excuse any typos): > >typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0; >ControlProcPtr gOldTrap; > >#pragma parameter __D0 main(__A0) >OSErr main(ParmBlkPtr pb); > >OSErr main(ParmBlkPtr pb:__A0):__D0 >{ > TCPiopb *tcpPB = (TCPiopb)pb; > > if (pb->csCode == TCPSend) > { > // I can't remember the exact code here, but it goes something like this: > // get stream ptr from tcpPB and stuff it into a TCPStatus PB > if (PBControlSync(statusPB) == noErr) > { > if (statusPB.remotePort == 25) [SMTP] > { > // wdsEntry *theWDS = the WDS from tcpPB ; > while (theWDS->length) > { > //if (theWDS->ptr == pattern) > // beep (will eventually do things to WDS contents) > else theWDS++; > } > } > } > gOldTrap(pb); >} > >I might have to dig up the real code and post it. Anyway, can anyone see >anything obviously dangerous in the above? What about calling thru to the original trap with the proper mixed mode call? I patched _PBMountVol and the guts of the patch looked like this: #if !GENERATINGCFM OSErr main (ParmBlkPtr PBPtr:__A0):__D0 #else ProcInfoType __procinfo = uppPBMountVolProcInfo; OSErr main (unsigned short TrapWord,ParmBlkPtr PBPtr) #endif { #if !GENERATINGCFM // Set up "A4 World" long SavedA4 = SetCurrentA4(); #endif // Get globals Err = Gestalt(gestaltGlobals,(long*)&Globals); if (Err != noErr) { DebugStr("\p_Gestalt FAILED"); goto Done; } // Call old trap #if GENERATINGCFM // DebugStr("\pPPC;G"); Err = CallOSTrapUniversalProc((*Globals).OldPBMountVol,uppPBMountVolProcInfo,TrapWord,PBPtr); if (Err != noErr) { DebugStr("\p_CallOSTrapUniversalProc((*Globals).OldPBMountVol) FAILED"); goto Done; } #else // DebugStr("\p68K;G"); Err = ((PBMountVolProc)((*Globals).OldPBMountVol))(PBPtr); if (Err != noErr) { DebugStr("\p(*Globals).OldPBMountVol() FAILED;G"); goto Done; } #endif // Body of function (this is a "head" patch) Done: #if !GENERATINGCFM SetA4(SavedA4); #endif return Err; } The different function prototypes was something to do with Metrowerks pushing the TrapWord on the stack for OS traps (this may not be required anymore??). A ptr to my globals was stored as a Gestalt value (check out the GestaltValue libraries around the place). On thinking about it, I may not have needed the "#if GENERATINGCFM" in the body of the function as this functionality is probably provided in CallOSTrapUniversalProc. Hope this helps... Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x5602 Fax: +64 9 373-7453 Async, Therefore I Am. - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From jwwalker@millennianet.com (James W. Walker) Date: Mon, 12 Feb 1996 21:32:51 -0800 Organization: Nisus Software, Inc. In article <nigel.stanger-1302961418000001@ou176027.otago.ac.nz>, nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) wrote: >My code looks something roughly like this (CW8, BTW, and excuse any typos): >typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0; >ControlProcPtr gOldTrap; >#pragma parameter __D0 main(__A0) >OSErr main(ParmBlkPtr pb); >OSErr main(ParmBlkPtr pb:__A0):__D0 >{ ... stuff deleted > gOldTrap(pb); >} A couple of ideas: 1. Your function fails to return a value. Was that just a typo in your post, or a real error? 2. _Control needs to look at register D1 to tell whether it is a synchronous or asynchronous call, right? But by the time you call gOldTrap, your code may have munged D1. For that matter, are you sure you don't need to know if you're synchronous? -- -- Jim Walker +++++++++++++++++++++++++++ >From pottier@drakkar.ens.fr (Francois Pottier) Date: 13 Feb 1996 13:31:46 GMT Organization: Ecole Normale Superieure, Paris, France In article <nigel.stanger-1302961418000001@ou176027.otago.ac.nz>, Nigel Stanger <nigel.stanger@stonebow.otago.ac.nz> wrote: > // I can't remember the exact code here, but it goes something like this: > // get stream ptr from tcpPB and stuff it into a TCPStatus PB > if (PBControlSync(statusPB) == noErr) You're making a synchronous call at interrupt time here. Are you sure this is OK? I'm no expert in these matters, but I think you might have to make an asynchronous call (only if your patch was called asynchronously, of course) and do the rest of your stuff from the completion routine. Just my $0.01, -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ +++++++++++++++++++++++++++ >From devon@apple.com (Devon Hubbard) Date: Tue, 13 Feb 1996 12:32:31 -0800 Organization: Apple Computer In article <chris-b-1302961651530001@hmu104.hmu.auckland.ac.nz>, chris-b@cs.auckland.ac.nz (Chris Burns) wrote: [original text/reply snipped] > The different function prototypes was something to do with Metrowerks > pushing the TrapWord on the stack for OS traps (this may not be required > anymore??). Quick fyi here. The requirement for the trap word to be the first parameter in patched OS traps IS NOT a necessity brought on my CodeWarrior. It's a requirement for patching OS traps period. Look at IM PowerPC System Software for the details (sorry I don't have the page # handy). If you are patching any OS trap, you will get and have to pass through the trap word as the first parameter. Before even attempting to suggest things for the crash itself, can you post/send the source for your patching and UPP procInfo declarations? Cheers, dEVoN +++++++++++++++++++++++++++ >From nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) Date: 14 Feb 1996 01:17:48 GMT Organization: Dept. of Information Science, University of Otago In article <chris-b-1302961651530001@hmu104.hmu.auckland.ac.nz>, chris-b@cs.auckland.ac.nz (Chris Burns) wrote: > What about calling thru to the original trap with the proper mixed mode > call? I patched _PBMountVol and the guts of the patch looked like this: [...snip...] This is something I thought of the other day, but I didn't know enough about the mechanics of mixed mode stuff to figure out how to do it (I've read the article in develop 16, but that's about it). Your example might be enough for me to figure out what to do. I'll try it and see. Thanks! ===================================================================== Nigel Stanger, Internet: nigel.stanger@stonebow.otago.ac.nz University of Otago, Phone: +64 3 479-8179 Dunedin, NEW ZEALAND. Fax: +64 3 479-8311 +++++++++++++++++++++++++++ >From nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) Date: 15 Feb 1996 22:23:16 GMT Organization: Dept. of Information Science, University of Otago In article <jwwalker-1202962132510001@dialppp-1-28.millennianet.com>, jwwalker@millennianet.com (James W. Walker) wrote: > A couple of ideas: > > 1. Your function fails to return a value. Was that just a typo in your > post, or a real error? It's just a typo. The real code actually looks like this: OSErr theErr; ... theErr = gOldTrap(pb); ... return theErr; > 2. _Control needs to look at register D1 to tell whether it is a > synchronous or asynchronous call, right? But by the time you call > gOldTrap, your code may have munged D1. For that matter, are you sure you > don't need to know if you're synchronous? Now that's a damn good point, and something that doesn't seem to be very well documented (I certainly haven't seen it anywhere obvious). Any suggestions on how to stop it getting stomped on? As to whether it's sync or async, I don't think it really matters from the point of view of my code. What I'm doing is inspecting the contents of the outgoing SMTP stream, and changing certain elements of it (for useful purposes I might add :) Whether it's async or sync is pretty much irrelevant, I think. ===================================================================== Nigel Stanger, Internet: nigel.stanger@stonebow.otago.ac.nz University of Otago, Phone: +64 3 479-8179 Dunedin, NEW ZEALAND. Fax: +64 3 479-8311 +++++++++++++++++++++++++++ >From jlscott@tigr.org (John L. Scott) Date: Fri, 16 Feb 1996 15:40:25 GMT Organization: The Institute for Genomic Research In article <nigel.stanger-1602961125180001@ou176027.otago.ac.nz>, nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) wrote: > In article <jwwalker-1202962132510001@dialppp-1-28.millennianet.com>, > jwwalker@millennianet.com (James W. Walker) wrote: > > > 2. _Control needs to look at register D1 to tell whether it is a > > synchronous or asynchronous call, right? But by the time you call > > gOldTrap, your code may have munged D1. For that matter, are you sure you > > don't need to know if you're synchronous? > > Now that's a damn good point, and something that doesn't seem to be very > well documented (I certainly haven't seen it anywhere obvious). Any > suggestions on how to stop it getting stomped on? In CodeWarrior at least, you can do this: #pragma parameter __D0 MyPBControl(__D1, __A0) pascal OSErr MyPBControl(unsigned short trapWord, TCPParmBlkPtr paramBlock) > As to whether it's sync or async, I don't think it really matters from the > point of view of my code. What I'm doing is inspecting the contents of the > outgoing SMTP stream, and changing certain elements of it (for useful > purposes I might add :) Whether it's async or sync is pretty much > irrelevant, I think. Ah but it is relevant. If you make a synchronous call to a device driver at interupt time, you may deadlock the driver. If you want to intercept asynchronous call you'll have to make your calls asynchronous as well. I wouldn't worry about using a completion routine though. Make your call and busy-wait until it's complete, then move on. This scheme should work whether the intercepted call is asyncronous or not. --John Scott +++++++++++++++++++++++++++ >From nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) Date: 19 Feb 1996 01:18:08 GMT Organization: Dept. of Information Science, University of Otago In article <jlscott-1602961040250001@192.207.234.72>, jlscott@tigr.org (John L. Scott) wrote: > In CodeWarrior at least, you can do this: > > #pragma parameter __D0 MyPBControl(__D1, __A0) > > pascal OSErr MyPBControl(unsigned short trapWord, TCPParmBlkPtr paramBlock) Yep, I thought of that myself, tried it a couple of nights ago, and now it works! No more crashes! Whee! :) > Ah but it is relevant. If you make a synchronous call to a device driver > at interupt time, you may deadlock the driver. If you want to intercept > asynchronous call you'll have to make your calls asynchronous as well. I > wouldn't worry about using a completion routine though. Make your call > and busy-wait until it's complete, then move on. This scheme should work > whether the intercepted call is asyncronous or not. Oh, OK, I should be able to code that in about 10 minutes. Thanks! ===================================================================== Nigel Stanger, Internet: nigel.stanger@stonebow.otago.ac.nz University of Otago, Phone: +64 3 479-8179 Dunedin, NEW ZEALAND. Fax: +64 3 479-8311 --------------------------- >From Andrew Welch <andrew@AmbrosiaSW.com> Subject: FastRandom() source Date: Tue, 13 Feb 1996 18:54:00 -0500 Organization: Ambrosia Software, Inc. While converting an application to be PowerPC native, I noticed that an A-Trap it made heavy use of (_Random) was not yet native. So I did a quick and dirty translation of the _Random 68K assembler code into C. It's pretty self-explanitory -- call FastRandom(0) to initialize the random number seed, or pass any positive value in the range parameter to generate a psuedo-random number between 0..range - 1 Enjoy... and remember, you get what you pay for. :) // - ---------------------------------------------------------------------------- - - // -- Return a random value between 0 and range - 1 short FastRandom(short range) { short result; static unsigned long randomSeed; register unsigned long calc; register unsigned long regD0; register unsigned long regD1; register unsigned long regD2; if (range == 0) randomSeed = LMGetTicks() + LMGetTime(); else { calc = randomSeed; regD0 = 0x41A7; regD2 = regD0; regD0 *= calc & 0x0000FFFF; regD1 = regD0; regD1 = regD1 >> 16; regD2 *= calc >> 16; regD2 += regD1; regD1 = regD2; regD1 += regD1; regD1 = regD1 >> 16; regD0 &= 0x0000FFFF; regD0 -= 0x7FFFFFFF; regD2 &= 0x00007FFF; regD2 = (regD2 << 16) + (regD2 >> 16); regD2 += regD1; regD0 += regD2; if (regD0 < 0) regD0 += 0x7FFFFFFF; randomSeed = regD0; if ((regD0 & 0x0000FFFF) == 0x8000) regD0 &= 0xFFFF0000; // -- Now that we have our pseudo random number, pin it to the range we want regD1 = range; regD1 *= (regD0 & 0x0000FFFF); regD1 = (regD1 >> 16); result = regD1; } return result; } // -- FastRandom -- +--------------------------------------------------------------+ | Andrew Welch - Thaumaturgist - Ambrosia Software, Inc. | +-------------------------------+------------------------------+ | AOL-> Keyword: Ambrosia | eWorld-> Shortcut: Ambrosia | | CIS-> GO word: Ambrosia | http://www.AmbrosiaSW.com/ | +-------------------------------+------------------------------+ +++++++++++++++++++++++++++ >From michel_saucier@cmq.qc.ca (Michel Saucier) Date: Sat, 17 Feb 1996 16:20:14 -0400 Organization: Bell Global Solutions About FastRandom()... Here is another algorithm to generate pseudorandom values. It's quite fast, faster than the classic congruential method, and generates 32 random bits at each call, instead of 16. It uses only XOR and AND, (no MULT, DIV or MOD). It needs a 1024 bits seed (32 longints) and has a period of 4294967295. Changing the seed values gives a completely different sequence, instead of merely changing the starting point. The function is only two lines of C. The only hard part is to initialize the startup array with 32 uncorrelated full-32 bits values, a non-trivial task, as the NetScape's folks can attest! This is left as an exercice. The code: static unsigned long AInd=0; static unsigned long AMem[32]; unsigned long alea(void) /* LFSR-based random generator, with a 32 longwords memory */ { unsigned long i=AInd++%32; /* 32 LFSR are maintained in parallel, bitwise */ return AMem[i]^=AMem[(i+1)%32]^AMem[(i+2)%32] ^AMem[(i+4)%32]^AMem[(i+6)%32]^AMem[(i+31)%32]; } And the related functions: long ralea(long range) /* return a pseudorandom value in 1..range */ {return 1+alea()%range;} static long LHseed=1; /* please kindly CHANGE ME */ unsigned long lehmer(void)/* Lehmer algorithm, Schrage's method to avoid overflow */ {long hi=LHseed/127773L,lo=LHseed%127773L; /* a very smart compiler would DIV once */ long t=lo*16807L - hi*2836L; return LHseed=(t>0)?t:t+2147483647L; } int checkAMem(void) /* 0 means AMem[] is unacceptable, 1 means OK */ { int i; unsigned long t; for(i=0,t=0;i<32;i++) t|=AMem[i]; /* Test AMem[] bitwise */ return 0==~t; /* all columns contain at least one non-zero bit? */ } void initAMem(void) /* stretches out a 31 bits seed to create 1024 bits seed. Avoid. */ { int i; LHseed=(long)clock(); for(i=0;i<32;i++) AMem[i]=lehmer()^lehmer()<<16; /* do not use this one in real life */ assert(0!=checkAMem()); /* should be extremely rare */ } Thou shalt not tamper with the alea() algorithm. It applies a CRC-type polynom bitwise, maintaining 32 LFSR-like sequences. Any "amelioration", like ADDing the 5 values instead of XORing them, or smartly ROTating the XOR result, is *VERY* likely to drastically _reduce_ the period of the generator. Consider this as a fair warning. And don't ever use alea() for cryptography. NO ONE ever abolish'd randomness by a crapshoot. (Mallarme) michel_saucier@cmq.qc.ca +++++++++++++++++++++++++++ >From michel_saucier@cmq.qc.ca (Michel Saucier) Date: Mon, 19 Feb 1996 00:14:17 -0400 Organization: Bell Global Solutions About alea()... static unsigned long AInd=0; static unsigned long AMem[32]; unsigned long alea(void) /* LFSR-based random generator, with a 32 longwords memory */ { unsigned long i=AInd++%32; /* 32 LFSR are maintained in parallel, bitwise */ return AMem[i]^=AMem[(i+1)%32]^AMem[(i+2)%32] ^AMem[(i+4)%32]^AMem[(i+6)%32]^AMem[(i+31)%32]; } The function is only two lines of C. The only hard part is to initialize the startup array with 32 uncorrelated full-32 bits values, a non-trivial task, as the NetScape's folks can attest! >> Andrew Welch - Thaumaturgist - Ambrosia Software, Inc. >> Interesting. How would you suggest initializing those values? In fact, if all you want is an honest and fast pseudo-random numbers generator, any set of 32 bits values is sufficient, provided no bit position contains a 0 on all 32 longwords, and there is no trivial pattern in the values. "0F0FF0F00F0F..." would definitvely be a bad startup seed. The checkAMem() will cause an assert() error for these degenerate cases. So you can use the MAC/OS (16 bits) or the C (31 bits) random generator, and use it to seed the AMem[] startup array. The period of the alea() generator will still be maximum. The only downside is that a 16 bits "streched seed" can only construct 32768 different startup arrays (each one producing 4294967295 random numbers without repetition), instead of having potentially 2^1024 different random generators, each one generating a unique sequence of 2^32 longwords of 32 random bits. Do you dig the difference ? It's only when you are using this random generator in cryptography that you MUST build a completely unguessable 1024 bits startup seed. There are many ways to achieve this: - Have the user flip a coin 1024 time (unobserved by anyone) and record the results. - Attach a Geiger counter to the computer. - Sample the ambiant noise by a microphone attached to the mac. - Have the user type a LONG passphrase. Discard the ASCII codes, use instead the timing between the keystrokes. - Build a composite of many values taken in the hardware or the operating system: clock, current address, timebase registers, performance registers, total number of cache hits, number of bytes processed by the file system, current mouse position, XOR of the display screen bitmap, current scanline, etc... etc.. See Bruce Shneier "Applied Cryptography", chapter 15, for more on this topic. See also Colin Plumb "Truly Random Numbers", Dr Dobb's Journal, November 1994, for a background task who collects mouseclics and keypresses, and integrates them in a pool "stirred" by the well-known hash MD5. ______________________________________________ I haven't yet timed my routine alea() against lehmer() on a PowerMac. On my 68040's 660AV, I have timed 350000 calls to alea() by second, against 142000/s for lehmer(), the typical congruential generator. If I optimize lehmer() in assembly, they are about the same speed. lehmer:: MOVE.L seed,D1 DIVS.L #127773,D0:D1 ; Quotient and remainder MULS.L #16807,D0 MULS.L #2836,D1 SUB.L D1,D0 BGT.S @1 ADD.L #1247483647,D0 @1: MOVE.L D0,seed RTS alea() is about 40 instructions long, but slightly faster because it contains no MULt, DIV nor BRanches, only XOR, ANDs, and addressing. There are 6 memory reads and 2 writes. When alea() is used to initialize a long list of random values, the AMem[] array fits nicely in the processor cache. I am still searching a way to increase the period of the generator to 2^1024, but any tampering, like INCrementing the XORed values, will void the mathematical property which assure of a 2^32-1 period. On can, of course, combine the output of the generator with another random generator of a different period. If the (parallel) LFSR is used alone, an astute cryptographer needs only 32 words or less known plaintext to reconstruct the initialisation vector and decrypt the mrest of the message(s). "God do not play with dice" A. Einstein Michel Saucier, michel_saucier@cmq.qc.ca +++++++++++++++++++++++++++ >From CatGuy@lamg.com (Milo Shiff) Date: 20 Feb 1996 07:17:43 GMT Organization: Los Angeles Macintosh Group BBS In message ID <31212498.12A8@AmbrosiaSW.com> on 2/13/96, andrew@AmbrosiaSW.com wrote: a> While converting an application to be PowerPC native, I noticed a> that an A-Trap it made heavy use of (_Random) was not yet native. a> So I did a quick and dirty translation of the _Random 68K a> assembler code into C. If speed is of utmost concern, build a table of random numbers at or before compile time. Make sure the table is large enough to meet your intended purposes. On the other hand, if a reliable pseudo-number generator is desired, use well proven methods, duplicated ubiquitously in various books. - Sent via BulkRate 2.1 --------------------------- >From Daniel Bogan <danielb@bighand.com.au> Subject: Hi ho, Hi ho, STR#ing we will go. Date: Fri, 02 Feb 1996 10:45:13 +1000 Organization: Big Hand Asia Pacific While i'm in a -in-need-of-help binge... Can someone supply me with code (THINK C) on how to write Str255's back out to a STR# resource. Say, I have 5 Str255's and I want to write them out to the one STR# resource in the order I supply. I'll probably think of something else to ask pretty soon. I can feel it. Ta. +++++++++++++++++++++++++++ >From svh+@pitt.edu (Shawn V. Hernan) Date: 2 Feb 1996 17:31:14 GMT Organization: The University of Pittsburgh In article <31115E99.47EA@bighand.com.au> Daniel Bogan <danielb@bighand.com.au> writes: > Can someone supply me with code (THINK C) on how to write Str255's > back out to a STR# resource. The press is in love with the World Wide Web, but usenet is still where all the cool stuff happens. Not two days ago, I had the same question. There is some good sample code at <http://www.AmbrosiaSW.com/cgi-bin/getsnippet.pl?file=/alt.sources.mac/s nippets-v01/packstr255> The basic idea is to implement the C structure yourself (an int followed by asciiz strings) and use AddResource (or similar) to actually do the writing. Two key points I discovered are : 1) If you're using an already exisitng resource, be sure to call DetachResource. 2) If you're building your own resource in memory be create a real handle using NewHandle or similar, and be sure to lock it prior to making changes. Thanks to Dave Nebinger, Jim Derry, Francis H. Shiffer, Paulo Casanova, Maf Vosburgh and others for the info . Shawn Shawn V. Hernan | Systems and Networks | The University of Pittsburgh | Dump the RICO Laws svh+@pitt.edu | 412-624-6425 | +++++++++++++++++++++++++++ >From yennie@aol.com (Yennie) Date: 5 Feb 1996 16:58:23 -0500 Organization: America Online, Inc. (1-800-827-6364) Something like this (warning this is Compileit! style junk and just a stab-- it might be useless) put newHandle(length(strings)+numStrings) into STRhand put STRhand@ into STRptr HLock STRhand put STR1 into STRptr@.str255Type put STRptr + (length(STR1)+1) into STRptr put STR2 into STRptr@.str255Type put STRptr + (length(STR2)+1) into STRptr put STR3 into STRptr@.str255Type put STRptr + (length(STR3)+1) into STRptr put STR4 into STRptr@.str255Type put STRptr + (length(STR4)+1) into STRptr put STR5 into STRptr@.str255Type HUnlock STRhand AddResource STRhand,bla bla,bla bla,bla bla --(I can't remember the order of params for "AddResource") WriteResource STRhand -- if you need it now Hope this helps... +++++++++++++++++++++++++++ >From dbrosius@chesco.com (Dave M Brosius) Date: 17 Feb 1996 08:00:37 GMT Organization: Chester County Internet Services, Inc. In article <31115E99.47EA@bighand.com.au>, danielb@bighand.com.au wrote: > While i'm in a -in-need-of-help binge... > > Can someone supply me with code (THINK C) on how to write Str255's > back out to a STR# resource. Say, I have 5 Str255's and I want to write > them out to the one STR# resource in the order I supply. > > I'll probably think of something else to ask pretty soon. I can feel it. > > Ta. Handle CreateStrPound( StringPtr *pStrings, long lStrCount ) { Handle hStrPound; char *pDst; long lCurString; long lSize; for (lCurString = 0, lSize = 0; lCurString < lStrCount; lSize += pStrings[lCurString][0] + 1, lCurString++ ); hStrPound = NewHandle( lSize ); ThrowIfNull( hStrPound ); // C++ was invented for those who don't // want to document error handling HLock( hStrPound ); for (lCurString = 0, pDst = *hStrPound; lCurString < lStrCount; pDst += pString[lCurString][0]+1, lCurString++ ) memcpy( pDst, pString[lCurString], ((unsigned char) pString[lCurString][0])+1 ); HUnlock( hStrPound ); return hStrPound; } -- Please reply via email as well dave dbrosius@chesco.com --------------------------- >From jrichmond@mcn.net (Jason Richmond) Subject: How do I switch printers without the Chooser? Date: Sat, 03 Feb 96 20:40:46 GMT Organization: Montana Communications Network I am writing an application for the Mac and I need to send output to two different network printers. I need to do this from within the program, hidden from the user. Is there any way to do this? +++++++++++++++++++++++++++ >From grinch@ns.moran.com (The Grinch) Date: 8 Feb 1996 21:56:22 GMT Organization: Vortex Software Don't quote me, but I think the answer lies in extended PRAM, which you're really not supposed to mess with. (Like that ever stops anybody.) As far as I know, the only way to change XPRAM is through assembly. If you figure it out, I'd love to see the source! Good luck! -The Grinch +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Sat, 10 Feb 1996 12:03:23 -0800 Organization: Cellular In article <4f06q3$ltp@news.mcn.net>, jrichmond@mcn.net (Jason Richmond) wrote: > I am writing an application for the Mac and I need to send output to two > different network printers. I need to do this from within the program, hidden > from the user. Is there any way to do this? No. Network printer drivers expect to be chosen with Chooser. In the case of LaserWriter, for example, when you choose a new printer, the driver verifies what kind of LaserWriter it is and chooses a PPD file for it. I expect other drivers perform similar stunts. If for some reason you are writing an application which is guranteed to run in a closed environment (ex.: LaserWriter guaranteed), you might choose to [a] select the generic LaserWriter PPD in Chooser, [b] have your program modify the 'PAPA' resource in the driver itself, [c] remove Chooser from the system so the user can't confuse things. Of course, this has a number of limitations, not least of which is it will eventually break, it will limit you to LaserWriters, it will disable any fun features of individual printers, etc. etc. - ----------------------------- Pete Gontier -- Apple Macintosh Developer Technical Support <URL:mailto:gurgle@dnai.com> -- <URL:http://www.dnai.com/~gurgle> +++++++++++++++++++++++++++ >From carl.gustafson@ece.drexel.edu (Carl Gustafson) Date: Mon, 12 Feb 1996 12:42:17 -0500 Organization: Imaging and Computer Vision Center, Drexel University In article <4f06q3$ltp@news.mcn.net>, jrichmond@mcn.net (Jason Richmond) wrote: > I am writing an application for the Mac and I need to send output to two > different network printers. I need to do this from within the program, hidden > from the user. Is there any way to do this? There are a few resources in the System file that tell what printer driver and printer to use. Changing them will change the selected printer, but I don't recall what the resources are, nor do I particularly recommend doing it. OTOH, it is a free country, so try if you like. -- Carl Gustafson Imaging and Computer Vision Center Drexel University, Philadelphia, Penna - ---------------------------------------------------------- I don't speak for Drexel, and Drexel doesn't listen to me... +++++++++++++++++++++++++++ >From dschwarz@netcom.com (Dan Schwarz) Date: Wed, 21 Feb 1996 03:37:32 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article <4f06q3$ltp@news.mcn.net>, jrichmond@mcn.net (Jason Richmond) wrote: > I am writing an application for the Mac and I need to send output to two > different network printers. I need to do this from within the program, hidden > from the user. Is there any way to do this? Yes, but it's an awful lot of work. My shareware program, "PrinterSwitch" does this; it took a couple weeks of (part-time) coding to get the switching code working properly. You can check it out at: http://www.cs.brandeis.edu/~dan/home.html Basically, what you have to do is this: Write the appropriate 'alis' and 'STR ' resources into the System file, these point to the printer driver you want to use. Write the appropriate 'PAPA' and/or 'PSEL' resourcs into the printer driver's resource fork. Switch to the appropriate parsed PPD file (if you're using LaserWriter 7 or 8 drivers) ... but where to find the "appropriate" resources and PPD resources to use? aha! that's the tough part. You have to make the user switch to the printer(s) that are to be used, each in turn, then your code will have to read in these resources and store them away safely somewhere. That's what I do. If you have total control over the environment in which your application is to be used, i.e. this is an in-house application to run on one system, you can prep this stuff ahead of time and store it in your application. For more info, I highly recommend reading Apple's Printing Q&As, and the issue of Develop magazine that talked about fun with PRGeneral and other printing tips. You can find both on the web, at http://www.dev.info.apple.com/ good luck! _Dan --------------------------- >From Lawson English <english@primenet.com> Subject: On obtaining rowBytes... (Was Re: Video Memory Access) Date: 11 Feb 1996 09:26:02 -0700 Organization: Primenet (602)395-1010 Chris De Salvo <phixus@deltanet.com> wrote: [snipt] : rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF; All the working code samples that I have uses 0x3fff, not 0x7fff. Anyone know if it makes any difference in the real world? -- - ----------------------------------------------------------------------------- Lawson English __ __ ____ ___ ___ ____ english@primenet.com /__)/__) / / / / /_ /\ / /_ / / / \ / / / / /__ / \/ /___ / - ----------------------------------------------------------------------------- +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Sun, 11 Feb 1996 10:32:12 -0800 Organization: Internet for the Olympic Peninsula In article <4fl5aq$t7c@nnrp1.news.primenet.com>, Lawson English <english@primenet.com> wrote: >Chris De Salvo <phixus@deltanet.com> wrote: >[snipt] >: rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF; > >All the working code samples that I have uses 0x3fff, not 0x7fff. > > >Anyone know if it makes any difference in the real world? Hi, Lawson, I'm not sure it makes any current real-world difference. However, the value rowBytes is specified as being less than 0x4000 (IM: Imaging with QuickDraw, page 4-47), and the top two bits are specified as being used as flags. No use of bit 14 is given on that page (leaving a few other IM pages where it might be--a check of Advanced Color Imaging would be a good idea, but I can't lay hands on it in paper form right now and don't feel like checking a CD version). --John -- The primary cause of problems is solutions. John W. Baxter Port Ludlow, WA jwbaxter@olympus.net +++++++++++++++++++++++++++ >From dmpalmer@clark.net (David M. Palmer) Date: 11 Feb 1996 13:51:14 -0500 Organization: Clark Internet Services, Inc., Ellicott City, MD USA Lawson English <english@primenet.com> writes: >Chris De Salvo <phixus@deltanet.com> wrote: >[snipt] >: rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF; >All the working code samples that I have uses 0x3fff, not 0x7fff. >Anyone know if it makes any difference in the real world? I believe it does. I seem to remember seeing Rowbytes 0xC??? on something I was doing recently, possibly in a GWorld. I didn't see the basenote, so I don't know if this has been mentioned, but other things I have learned about GWorlds, which you may as well do even if you are using screen memory: Make sure that you use GetPixBaseAddress(pixmap), or whatever the call is, to get the address of the actual pixels. (Sometimes pixmap.baseaddress is a pointer, and sometimes a handle, depending.) And call SetPixelsState(pixmap, LockPixels) if you do something that might move memory after you get the address. -- David Palmer dmpalmer@clark.net +++++++++++++++++++++++++++ >From verec@micronet.fr (Jean-Francois Brouillet) Date: Mon, 12 Feb 1996 21:12:57 +0100 Organization: Francenet -- Paris, France In article <4fldr2$aup@clark.net>, dmpalmer@clark.net (David M. Palmer) wrote: >Lawson English <english@primenet.com> writes: [question about mask to apply to rowBytes (0x7fff or 0x3fff)] Using DejaNews, I found the following article which may explain what these bits are used for... Here's the entire article (which deals with how to retreive the palette stored within a PICT file). The portion relevant to this thread is in the ColorBitsProc routine... hope this helps... [BTW: I needed some thing like this, ant this code does work!] sender: mars@netcom15.netcom.com references: <marsDGGzu9.EMF@netcom.com> <466grp$3ul@crl14.crl.com> content-type: text/plain; charset=ISO-8859-1 organization: NETCOM On-line Communication Services (408 261-4700 guest) mime-version: 1.0 newsgroups: comp.sys.mac.programmer.help In article <466grp$3ul@crl14.crl.com> John S. Heaney, heaney@crl.com writes: >In article <marsDGGzu9.EMF@netcom.com>, Darren Giles <mars@netcom.com> wrote: >>I need to get a color table out of an 8-bit PICT. I know one way to do >>it is to use GetPictInfo, which generates a color table based on the >>pixels it sees in the picture... but I need to get the original color >>table. > >I've wanted to do that, too. I'm surprised that there doesn't seem to be >a way to do this built into the toolbox, considering all the other >powerful tools. No kidding! Well, I've patched together a start based on the CollectPictColors snippet (using the QDraw bottleneck idea, as Nicholas (and DTS) suggested). Here's what I've got so far, in case others are trying to do the same: - Darren CTabHandle gColorTable; /* to collect colors from bottlenecks. */ /////////////////////////////////////////////////////////////////////// ///////////////// // Looks though the PICT, returns a copy of the CLUT of the first bitmap it encounters. /////////////////////////////////////////////////////////////////////// ///////////////// CTabHandle CollectColors (PicHandle fromPicture) { CQDProcs bottlenecks; if (!fromPicture) { return nil; } /* Set the bottlenecks. These bottlenecks will figure out what colors are in a picture, but won't draw anything. Note: the bottlenecks are installed in thePort, which must be a color port. */ SetStdCProcs(&bottlenecks); bottlenecks.textProc = nil; bottlenecks.lineProc = nil; bottlenecks.rectProc = nil; bottlenecks.rRectProc = nil; bottlenecks.ovalProc = nil; bottlenecks.arcProc = nil; bottlenecks.polyProc = nil; bottlenecks.rgnProc = nil; bottlenecks.bitsProc = NewQDBitsProc (ColorBitsProc); gColorTable= nil; /* Now play back the picture to get the colors. The dstRect doesn't matter since our bottlenecks will never actually draw. We use global variables (gColorError and gColorTable) to communicate with the bottlenecks. */ (*(qd.thePort)).grafProcs = (QDProcs *) &bottlenecks; DrawPicture(fromPicture, &((**fromPicture).picFrame)); (*(qd.thePort)).grafProcs = 0L; return gColorTable; } /////////////////////////////////////////////////////////////////////// ///////////////// pascal void ColorBitsProc(BitMap *bitPtr, Rect *srcRect, Rect *dstRect, short mode, RgnHandle maskRgn) { #pragma unused (srcRect, dstRect, mode, maskRgn) PixMapPtr aPixMap; short tempRB; Handle CTHandle; /* Get the PixMap that we are about to draw. SrcBits might be a BitMap, or one of two different kinds of PixMap pointers. */ tempRB = (*bitPtr).rowBytes; /* local copy of rowBytes */ if (tempRB & 0x8000) { /* high bit set? */ if (tempRB & 0x4000) { /* next to high bit set? */ /* ptr to PixMap handle */ aPixMap = (** ( (PixMapHandle *)bitPtr )); } else { /* pointer to a PixMap */ aPixMap = (PixMapPtr) bitPtr; } if ((*aPixMap).pixelType==16) { return; /* direct pixmap? eek! */ } if (!gColorTable) { CTHandle= (Handle) (*aPixMap).pmTable; gColorTable= (CTabHandle) NewHandle (GetHandleSize (CTHandle)); BlockMove (*CTHandle, *gColorTable, GetHandleSize (CTHandle)); } } } -- Jean-Francois Brouillet verec@micronet.fr Macintosh Software Developer verecundus@eworld.com +++++++++++++++++++++++++++ >From kluev@macsimum.gamma.ru (Kluev) Date: Tue, 13 Feb 96 19:08:42 +0300 Organization: (none) In article <jwbaxter-1102961032120001@ptpm022.olympus.net>, jwbaxter@olympus.net (John W. Baxter) wrote: >In article <4fl5aq$t7c@nnrp1.news.primenet.com>, Lawson English ><english@primenet.com> wrote: > >>Chris De Salvo <phixus@deltanet.com> wrote: >>[snipt] >>: rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF; >> >>All the working code samples that I have uses 0x3fff, not 0x7fff. >> >> >>Anyone know if it makes any difference in the real world? > > I'm not sure it makes any current real-world difference. However, the >value rowBytes is specified as being less than 0x4000 (IM: Imaging with >QuickDraw, page 4-47), and the top two bits are specified as being used as >flags. No use of bit 14 is given on that page (leaving a few other IM >pages where it might be--a check of Advanced Color Imaging would be a good >idea, but I can't lay hands on it in paper form right now and don't feel >like checking a CD version). They were just too lazy to point out in IM that the *only* bit is used to distinguish between color and b&w BitMaps, and the only case when the *second* bit is used is when you pass PixMap as a parameter to CopyBits procedure. The latter restriction could be bypassed via several ways. - -------------------------------------------------------------- Michael Kluev kluev@macsimum.gamma.ru Macintosh Programmer Physics Grad, MSU MACsimum Ltd. Moscow, Russia - -------------------------------------------------------------- +++++++++++++++++++++++++++ >From Mark Williams <Mark@streetly.demon.co.uk> Date: Tue, 13 Feb 96 07:14:23 GMT Organization: Streetly Software In article <verec-1202962112570001@ppp94.micronet.fr>, Jean-Francois Brouillet writes: > > In article <4fldr2$aup@clark.net>, dmpalmer@clark.net (David M. Palmer) wrote: > > >Lawson English <english@primenet.com> writes: > > [question about mask to apply to rowBytes (0x7fff or 0x3fff)] > [snip] > SetStdCProcs(&bottlenecks); [snip] > bottlenecks.bitsProc = NewQDBitsProc (ColorBitsProc); > > /////////////////////////////////////////////////////////////////////// > ///////////////// > pascal void ColorBitsProc(BitMap *bitPtr, Rect *srcRect, Rect *dstRect, > short mode, RgnHandle maskRgn) { > #pragma unused (srcRect, dstRect, mode, maskRgn) > PixMapPtr aPixMap; > short tempRB; > Handle CTHandle; > > > /* Get the PixMap that we are about to draw. SrcBits might be a BitMap, > or one of two different kinds of PixMap pointers. */ > > tempRB = (*bitPtr).rowBytes; /* local copy of rowBytes */ > if (tempRB & 0x8000) { /* high bit set? */ > if (tempRB & 0x4000) { /* next to high bit set? */ > /* ptr to PixMap handle */ > aPixMap = (** ( (PixMapHandle *)bitPtr )); > } > else { > /* pointer to a PixMap */ > aPixMap = (PixMapPtr) bitPtr; > } > > if ((*aPixMap).pixelType==16) { > return; > /* direct pixmap? eek! */ > } > > if (!gColorTable) { > CTHandle= (Handle) (*aPixMap).pmTable; > gColorTable= (CTabHandle) NewHandle (GetHandleSize (CTHandle)); > BlockMove (*CTHandle, *gColorTable, GetHandleSize (CTHandle)); > } > } > } The "if (tempRB & 0x4000)" line will always be false. CopyBits looks at that bit and if its set it dereferences the pixmap _before_ calling the bottleneck bitsProc (oh, and by the way it doesnt HLock the PixMapHandle first either, so on entry bitPtr could be a pointer to an unlocked, dereferenced PixMap). This means that if you call StdBits rather than copybits, you can use a rowbytes value of up to 0x7fff (This was documented once in a technote I think, but is probably unsupported). - -------------------------------------- Mark Williams<Mark@streetly.demon.co.uk> +++++++++++++++++++++++++++ >From dbrosius@chesco.com (Dave M Brosius) Date: 17 Feb 1996 07:52:34 GMT Organization: Chester County Internet Services, Inc. In article <4fl5aq$t7c@nnrp1.news.primenet.com>, Lawson English <english@primenet.com> wrote: > Chris De Salvo <phixus@deltanet.com> wrote: > [snipt] > : rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF; > > All the working code samples that I have uses 0x3fff, not 0x7fff. > > > Anyone know if it makes any difference in the real world? Yes! use 0x3FFF... I think bit 14 means that no color table mapping occurs... ie source pixmaps are drawn using the color indexes of the gworlds pixmap. -- Please reply via email as well dave dbrosius@chesco.com +++++++++++++++++++++++++++ >From sw@nan.co.uk (Sak Wathanasin) Date: Sat, 17 Feb 1996 14:35:23 GMT Organization: Network Analysis Ltd In article <96021307142300261@streetly.demon.co.uk>, Mark@streetly.demon.co.uk wrote: > This means that if you call StdBits rather than copybits, you can use a > rowbytes value of up to 0x7fff (This was documented once in a technote I > think, but is probably unsupported). As an aside, QD will cheerfully let you create pixmaps whose rowBytes are longer than 0x3fff, but will, er, "behave strangely" you attempt to CopyBits from such a pixmap. It does seem to let one CopyBits to such a pixmap though. It's quite easy to generate such a pixmap in PhotoShop: I was downsampling Scitex CT files, and by mistake the test file that I made with Photoshop was 72 dpi instead of the 300 dpi that I had intended, and it killed my appl. I've fixed it now, but it took me ages to work out what was going on... -- Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@nan.co.uk uucp: ...!britain.eu.net!nan!sw Phone: (+44) 1203 419996 Fax: (+44) 1203 690690 +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Sun, 18 Feb 1996 13:22:16 GMT Organization: Network Analysis Ltd In article <jwbaxter-1102961032120001@ptpm022.olympus.net>, jwbaxter@olympus.net (John W. Baxter) wrote: > I'm not sure it makes any current real-world difference. However, the > value rowBytes is specified as being less than 0x4000 (IM: Imaging with > QuickDraw, page 4-47), and the top two bits are specified as being used as > flags. No use of bit 14 is given on that page (leaving a few other IM Doesn't CopyBits use it to tell whether you've called LockPixels on the pixmap? Can't remember where I saw this though, so it might be a figment of my imagination... -- Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@nan.co.uk uucp: ...!britain.eu.net!nan!sw Phone: (+44) 1203 419996 Fax: (+44) 1203 690690 +++++++++++++++++++++++++++ >From matt@lantic.idiscover.co.uk (Matt Gough) Date: Sat, 17 Feb 1996 21:23:09 +0000 Organization: Internet Discovery Ltd > >I think bit 14 means that no color table mapping occurs... ie source >pixmaps are drawn using the color indexes of the gworlds pixmap. > Bit 14 tells Qd internally that the pixmap was created for a GWorld, and that it has to RecoverHandle on the baseAddr to get the real pixmap data. Matt Gough +++++++++++++++++++++++++++ >From kluev@macsimum.gamma.ru (Kluev) Date: Mon, 19 Feb 96 18:17:05 +0300 Organization: (none) In article <dbrosius-1702960213070001@pm1x20.chesco.com>, dbrosius@chesco.com (Dave M Brosius) wrote: >I think bit 14 means that no color table mapping occurs... ie source >pixmaps are drawn using the color indexes of the gworlds pixmap. In article <matt-1702962123090001@lantic.idiscover.co.uk>, matt@lantic.idiscover.co.uk (Matt Gough) wrote: >Bit 14 tells Qd internally that the pixmap was created for a GWorld, and >that it has to RecoverHandle on the baseAddr to get the real pixmap data. People, please stop this mess. Bit 14 in rowBytes has nothing to do with color-remapping blocking (ctFlags field of color table does it), nor with the state of baseAddr block (pmVersion field of PixMap does it). RowBytes' bit 14 is only getting used within CopyBits call to distinguish between color grafports and bitmaps/pixmaps. BTW, among the list of groups: comp.sys.mac.graphics, comp.sys.mac.programmer.help, comp.sys.mac.programmer.games, comp.sys.mac.programmer.tools, comp.sys.mac.programmer.codewarrior only comp.sys.mac.programmer.help has to do with the question. So I removed other groups from news-header. - -------------------------------------------------------------- Michael Kluev kluev@macsimum.gamma.ru Macintosh Programmer Physics Grad, MSU MACsimum Ltd. Moscow, Russia - -------------------------------------------------------------- --------------------------- >From nolanw@iglou.com (Nolan W. Whitaker) Subject: PEF (Preferred Executable Format) Info Needed Date: Sun, 11 Feb 1996 01:53:07 GMT Organization: IgLou Internet Services (1-800-436-4456) I have been desperately searching for documentation on the Preferred Executable Format used for binary files on the Mac and the BeBox. I assumed that Inside Macintosh would document this thoroughly, but the only reference I could find on my Inside Mac CD was a brief note in the PowerPC Systems book that stated essentially that Macs use PEF--- but no explanation or examples of the format. I've also searched the Web using a couple of different search engines without finding anything useful. I will be beginning a project for the BeBox very soon where I'll need to produce an executable file, but in order to due that I need to find a detailed explanation of the file format. Any ideas? Is this info available on any of the Apple developer CDs? A book? Thanks, Nolan ====================================================================== = nolanw@iglou.com || = = nolanw@ewl.uky.edu || http://www.ewl.uky.edu/~nolanw = ====================================================================== = ...waiting on that BeBox I ordered to arrive... = ====================================================================== +++++++++++++++++++++++++++ >From fnf@fishpond.amigalib.com (Fred Fish) Date: 13 Feb 1996 17:53:42 GMT Organization: Cronus In article <eric.kidd-1302961134120001@atgw-kip-1-141.dartmouth.edu>, Eric M. Kidd <eric.kidd@dartmouth.edu> wrote: >It seems, according to statements from MWRon, that PEF is a fairly >well-guarded Apple patent, with licensing agreements and whatnot. This >brings up a couple of issues. What is the patent number please. > * How are folks supposed to make GNU tools work on the PowerMac? My understanding is that the MacOS loads XCOFF as well as PEF, and that the current port of gcc to MacOS generates XCOFF executables. > * How are folks supposed to make GNU tools work on the BeBox? There are a number of possibilities for getting a gcc port that just compiles posix type apps (getting a full g++ port for doing Be specific things is much harder): (1) Add PEF support to the BFD library so that the linker can generate PEF executables. Note that it isn't necessary that the intermediate object files be PEF, though that would probably not be much more work to implement. This will require either having Apple become more open about supplying documentation on PEF without restriction, or reverse engineering the PEF format. I have a document that was written by someone who did just that, but I don't know how complete it is, with regards to being suitable for adding PEF support to the BFD library. (2) Use an XCOFF (or ELF) to PEF translator to convert the output of the linker to PEF format. For maximum compatibility this would have to be done by someone with access to the PEF documentation under NDA. They could then distribute BeOS binaries or possibly other binaries like linux, for those that are interested in initially building GNU cross environments to help in bootstrapping all the utilities to BeOS. One problem here is that we would need a reverse PEF to XCOFF translator to generate BeOS libraries that the GNU linker can use. Aside from being somewhat of a kludge, it this solution doesn't help for things like gdb ports, where the program has to be able to read the native executable format unless you want to keep both the XCOFF and PEF versions of each executable and attach to the running PEF version while reading symbols and such out of the XCOFF version. (3) Have gcc produce assembly files that are then fed to the current Metroworks tools for assembly and linkage. This is somewhat how early SVR4 gcc ports worked before the GNU tools fully supported ELF format. (4) If you just want ports of "GNU tools" but not necessarily gcc, then use the existing tools to build the GNU tools, as many people are already doing. Ideally the posix environment on BeOS needs to be as complete as possible, and this is currently being worked on AFAIK. Simple things already work, and some tools like sed compile almost unchanged. However other tools that depend heavily on things like signals, fork/exec, etc will take much more work with the current release. (5) There must be at least a couple other solutions :-) -Fred -- CRONUS -- 1840 E. Warner Road #105-265 -- Tempe, AZ 85284 -- USA Voice: (800) 804-0833 or (602) 491-0442 FAX: (602) 491-0048 Email: info@amigalib.com or info@ninemoons.com (coming soon) Ftp site: ftp.amigalib.com or ftp.ninemoons.com (coming soon) +++++++++++++++++++++++++++ >From ck@be.com (C.K. Haun) Date: Tue, 13 Feb 1996 11:38:47 -0800 Organization: Be, Inc. In article <DML8rA.M19@iglou.com>, nolanw@iglou.com (Nolan W. Whitaker) wrote: > I have been desperately searching for documentation on the > Preferred Executable Format used for binary files on the Mac The PEF format is proprietary to Apple and IBM, we are using it under license from Apple. It's not documented anywhere, except for some freeware documentation that someone reverse-engineered and posted here and there (I actually don't know where) and even that is not complete. Tools developers can license the format information from Apple, and when we finalized our licensing agreement with Apple we will be able to sub-license to our developers. Why is it so secret? Dont' really know, but it's the rules we have to play by. C.K. Haun <TR> The Developer Guy @ Be, Inc. ck@be.com The Mild Bunch 1996 Royal Star 1300 1991 Voyager 1200 1990 Virago 750 1993 Virago 535 1987 Reflex 225 <maybe a Valkirie soon?> +++++++++++++++++++++++++++ >From eric.kidd@dartmouth.edu (Eric M. Kidd) Date: Tue, 13 Feb 1996 11:34:12 -0500 Organization: Dartmouth College In article <DML8rA.M19@iglou.com>, nolanw@iglou.com (Nolan W. Whitaker) wrote: > I have been desperately searching for documentation on the > Preferred Executable Format used for binary files on the Mac > and the BeBox. > > I assumed that Inside Macintosh would document this thoroughly, > but the only reference I could find on my Inside Mac CD was a > brief note in the PowerPC Systems book that stated essentially > that Macs use PEF--- but no explanation or examples of the > format. It seems, according to statements from MWRon, that PEF is a fairly well-guarded Apple patent, with licensing agreements and whatnot. This brings up a couple of issues. * How are folks supposed to make GNU tools work on the PowerMac? * How are folks supposed to make GNU tools work on the BeBox? Just wondering. =) (This article is cross-posted, by the way. Please reset followups if it's about to get off topic in either newsgroup.) Cheers, Eric ........................................................................ Eric Kidd (eric.kidd@dartmouth.edu) http://coos.dartmouth.edu/~emk/ "Computers are useless. They can only give you answers." -Pablo Picasso +++++++++++++++++++++++++++ >From fnf@fishpond.amigalib.com (Fred Fish) Date: 13 Feb 1996 20:18:37 GMT Organization: Cronus In article <ck-1302961138470001@freud.be.com>, C.K. Haun <ck@be.com> wrote: >In article <DML8rA.M19@iglou.com>, nolanw@iglou.com (Nolan W. Whitaker) wrote: >Tools developers can license the format information from Apple, and when >we finalized our licensing agreement with Apple we will be able to >sub-license to our developers. Neither of these will help the people wanting to provide support for GNU tools on the BeBox unless the licensing explicitly allows releasing source code that makes use of information provided under the license agreement. -Fred -- CRONUS -- 1840 E. Warner Road #105-265 -- Tempe, AZ 85284 -- USA Voice: (800) 804-0833 or (602) 491-0442 FAX: (602) 491-0048 Email: info@amigalib.com or info@ninemoons.com (coming soon) Ftp site: ftp.amigalib.com or ftp.ninemoons.com (coming soon) +++++++++++++++++++++++++++ >From d88-bli@xbyse.nada.kth.se (Bo Lindbergh) Date: 14 Feb 1996 01:01:43 GMT Organization: Royal Institute of Technology, Stockholm, Sweden In article <4fqj76$f20@globe.indirect.com> fnf@fishpond.amigalib.com (Fred Fish) writes: ) ) My understanding is that the MacOS loads XCOFF as well as PEF, and ) that the current port of gcc to MacOS generates XCOFF executables. I can't get it to load an XCOFF executable, but there may be some magic incantation needed that I'm unaware of. ) (1) Add PEF support to the BFD library so that the linker ) can generate PEF executables. Note that it isn't necessary ) that the intermediate object files be PEF, though that would ) probably not be much more work to implement. PEF is not suitable for intermediate object files. /Bo Lindbergh +++++++++++++++++++++++++++ >From jayfar@netaxs.com (Jay Farrell) Date: Wed, 14 Feb 1996 00:32:11 -0500 Organization: Jayfar's Web In article <4fqrmt$i9h@globe.indirect.com>, fnf@fishpond.amigalib.com (Fred Fish) wrote: > In article <ck-1302961138470001@freud.be.com>, C.K. Haun <ck@be.com> wrote: > >In article <DML8rA.M19@iglou.com>, nolanw@iglou.com (Nolan W. Whitaker) wrote: > >Tools developers can license the format information from Apple, and when > >we finalized our licensing agreement with Apple we will be able to > >sub-license to our developers. > > Neither of these will help the people wanting to provide support for > GNU tools on the BeBox unless the licensing explicitly allows > releasing source code that makes use of information provided under the > license agreement. Damn. Is this yet another instance of Apple leaving P.D. language developers out in the cold? This same sort of situation appears to exist with OpenDoc. Although Apple's OpenDoc Programmers Guide states that OpenDoc parts can be written in any language, there are no IDL emitters to accommodate this AFAIK. Bring back Wozniak and put him in charge of R&D -- he'd kill all this secrecy. Cheers, Jayfar ///////////////////////////////////////////////////////////////////////////// ////// The Mops Page <URL:http://www.netaxs.com/~jayfar/mops.html> ////// ///////////////////////////////////////////////////////////////////////////// Jay Farrell jayfar@netaxs.com <URL:http://www.netaxs.com/~jayfar/> Philadelphia, Pennsylvania, USA Jayfar's Virtual Mac FTP Site +++++++++++++++++++++++++++ >From nolanw@iglou.com (Nolan W. Whitaker) Date: Wed, 14 Feb 1996 15:59:28 GMT Organization: IgLou Internet Services (1-800-436-4456) fnf@fishpond.amigalib.com (Fred Fish) wrote: >There are a number of possibilities for getting a gcc port that just >compiles posix type apps (getting a full g++ port for doing Be >specific things is much harder): ...misc deleted >(3) Have gcc produce assembly files that are then fed to the > current Metroworks tools for assembly and linkage. This is > somewhat how early SVR4 gcc ports worked before the GNU tools > fully supported ELF format. This is essentially what I think I'll be doing with at least one of my projects. As long as Be continues shipping a copy of the Metrowerks stuff with every machine and they don't change things too much, I think I'll be reasonably ok. Thanks for all the info guys! -Nolan ====================================================================== = nolanw@iglou.com || = = nolanw@ewl.uky.edu || http://www.ewl.uky.edu/~nolanw = ====================================================================== = ...waiting on that BeBox I ordered to arrive... = ====================================================================== +++++++++++++++++++++++++++ >From fnf@fishpond.amigalib.com (Fred Fish) Date: 14 Feb 1996 16:05:45 GMT Organization: Cronus In article <4frc9n$5eq@news.kth.se>, Bo Lindbergh <d88-bli@xbyse.nada.kth.se> wrote: > >PEF is not suitable for intermediate object files. Now that's interesting! I haven't examined the meager documentation I have on PEF yet in any detail, so I wasn't aware of that. I just assumed that since it was an XCOFF derivative, which is typically used for both the object and executable format, that it was the same for PEF. So that leads up to the question, what *is* the object file format that the MetroWerks compiler uses? Does this mean that if anyone wants to produce a fully compatible set of GNU tools that they not only have to deal with an undocumented object file format, they also have to deal with a (different) undocumented object file format and an undocumented library format? Gee, standard ELF objects/executables and standard unix style "ar" archives are sure starting to sound like a more appropriate longterm solution for what is being promoted as a hackers machine. :-) -Fred -- CRONUS -- 1840 E. Warner Road #105-265 -- Tempe, AZ 85284 -- USA Voice: (800) 804-0833 or (602) 491-0442 FAX: (602) 491-0048 Email: info@amigalib.com or info@ninemoons.com (coming soon) Ftp site: ftp.amigalib.com or ftp.ninemoons.com (coming soon) +++++++++++++++++++++++++++ >From triquet@supelec.fr (Benoit Triquet) Date: 14 Feb 1996 22:13:12 GMT Organization: SUPELEC Fred Fish (fnf@fishpond.amigalib.com) wrote: : So that leads up to the question, what *is* the object file format : that the MetroWerks compiler uses? Does this mean that if anyone : wants to produce a fully compatible set of GNU tools that they not : only have to deal with an undocumented object file format, they also : have to deal with a (different) undocumented object file format and an : undocumented library format? hd (/bin/hd on the bebox, hex dump) any .o file. you read MWOBPPC *WIN* the object format is a metrowerks thing. This story with PEF is becoming unpleasant... Our hacker open minded $50 licensing machine has it in the... Hey btw, JLG, how do you intend to deal with PEF in the $50 license fee for the BeOS ?? Benoit +++++++++++++++++++++++++++ >From aek@goonsquad.spies.com (Al Kossow) Date: 14 Feb 1996 17:49:21 -0800 Organization: Internet Wiretap >From article <4ftmpo$4vo@prof.ese-metz.fr>, by triquet@supelec.fr (Benoit Triquet): > Hey btw, JLG, how do you intend to deal with PEF in the $50 license fee for > the BeOS ?? > Has anyone tried contacting Apple about dropping the PEF license? I would think now would be a good time to try, given the current push to open up other parts of the system. +++++++++++++++++++++++++++ >From Mike Griebling <grieblm@es2> Date: 15 Feb 1996 12:10:47 GMT Organization: AlliedSignal Engines, Phoenix, Az Fred Fish writes: > In article <4frc9n$5eq@news.kth.se>, > Bo Lindbergh <d88-bli@xbyse.nada.kth.se> wrote: > > > >PEF is not suitable for intermediate object files. > > So that leads up to the question, what *is* the object file format > that the MetroWerks compiler uses? Does this mean that if anyone > wants to produce a fully compatible set of GNU tools that they not > only have to deal with an undocumented object file format, they also > have to deal with a (different) undocumented object file format and an > undocumented library format? Good question! Anyone at Be care to comment? > Gee, standard ELF objects/executables and standard unix style "ar" > archives are sure starting to sound like a more appropriate longterm > solution for what is being promoted as a hackers machine. :-) I agree 100%! > -Fred Regards, Michael - ------------------------------------------------------------ Michael Griebling, P. Eng. mgriebling@bix.com Computer Inspirations grieblm@trt.allied.com +++++++++++++++++++++++++++ >From hplus@bga.com (Jon Watte) Date: Thu, 15 Feb 1996 19:16:47 -0600 Organization: Rudimentary In article <4ft18p$da7@globe.indirect.com>, fnf@fishpond.amigalib.com (Fred Fish) wrote: > assumed that since it was an XCOFF derivative, which is typically used > for both the object and executable format, that it was the same for > PEF. PEF was invented by Apple because it is SUBSTANTIALLY more compact than XCOFF. Part of what makes it compact is the patented relocation mechanism. Part is all the "unnecessary" stuff they left out... However, PEF is still pretty flexible; you might for instance add some kind of external data (like application resources) to a PEF section without breaking tools that don't know about this special section. > So that leads up to the question, what *is* the object file format > that the MetroWerks compiler uses? Does this mean that if anyone The file type is "MPLF" which stands for the Metrowerks Preferred Link Format. It is geared towards supporting features of our development tools such as fast linking and good symbolics support. However, as we strive to improve the performance of our tools, we may change this format, even though it's been still for a long time now. What HAS changed is the requirements for runtime support glue, that's why some older libraries will not link with newly compiled applications. > wants to produce a fully compatible set of GNU tools that they not > only have to deal with an undocumented object file format, they also > have to deal with a (different) undocumented object file format and an > undocumented library format? If you're serious, we will most definately talk to you. We are working closely with several vendors on the Mac side who write compiler plug-ins for the IDE. Please talk to me in e-mail and I will forward your request if needed. Cheers, / h+ -- Jon Watte, Austin, TX Play: hplus@realtime.net; Work: h+@metrowerks.com "It's a joke, dammit!" +++++++++++++++++++++++++++ >From mike_duigou@fwb.com (Mike Duigou) Date: Sun, 18 Feb 1996 14:33:37 -0800 Organization: FWB Inc. In article <jayfar-1402960032110001@downtown1-36.slip.netaxs.com>, jayfar@netaxs.com (Jay Farrell) wrote: ... > >Damn. Is this yet another instance of Apple leaving P.D. language >developers out in the cold? > >This same sort of situation appears to exist with OpenDoc. Although >Apple's OpenDoc Programmers Guide states that OpenDoc parts can be written >in any language, there are no IDL emitters to accommodate this AFAIK. > >Bring back Wozniak and put him in charge of R&D -- he'd kill all this secrecy. > ... It occurs to me that most of this discussion is continuing on the basis of inuendo, rumor and suspicion, and not a whole lot on facts. Has anyone actually contacted Apple liscencing? I have yet to see anyone quote coorespondance from an Apple response which confirms or denys the alleged behaviour. One would assume that their respone would be the only thing that matters. Incidentally you can contact Apple liscencing at : mailto:sw.license@applelink.apple.com http://dev.info.apple.com/swl/swl.html Come on, this issue has been going on for weeks on the various Mac programming news groups with no new information being injected into the discussion. The general impression left is that its just a bunch of crabby malcontents bitching about Apple and the supposed subject matter (PEF file format) is not really the issue. Mike Duigou FWB Inc. -- "Me, when I have nothing to say, my lips are sealed." -- Talking Heads --------------------------- >From phoebel@nanaimo.island.net (Peter Hoebel) Subject: Reconnecting Mounted Appleshare Volumes Date: 20 Feb 1996 05:58:20 GMT Organization: Teranet IA Inc Greetings. I've got three related network issues I need help with. The first two are of a lower priority. The situation is this. In an appletalk zone one Mac mounts four other Macs. When one of these four shuts down the first mac displays the usual "the server ... has been unexpectedly shutdown at ..." dialog. Our application on the first Mac regularly copies files from the four mounted Macs. We're running 7.5.1. 1) Is there anyway to disable this message from even appearing or automatically emulating a return key being pressed if it is displayed? 2) Is there anyway to change the default timeout time, it's approximately 2 minutes in our LAN? 3) The initial mac needs to reconnect to the shutdown mac after it restarts which we're assuming is almost right away. This third question is the most important one. I believe one approach would be to resolve an alias to the volume, such as is stored in recent servers. More complicated would be to store an alias record of the volume when it first is mounted and then resolve it after it has rebooted. Is there anyway to reconnect without having to manage an alias in our code? Any guidance would be most welcome. Many thanks, Pete Hoebel phoebel@epaus.island.net +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 20 Feb 1996 02:59:20 -0500 Organization: America Online, Inc. (1-800-827-6364) > I've got three related network issues I need help with. The >first two are of a lower priority. The situation is this. In >an appletalk zone one Mac mounts four other Macs. When one of >these four shuts down the first mac displays the usual "the >server ... has been unexpectedly shutdown at ..." dialog. Our >application on the first Mac regularly copies files from the >four mounted Macs. We're running 7.5.1. > >1) Is there anyway to disable this message from even appearing >or automatically emulating a return key being pressed if it is >displayed? Get the AppleShareSetup control panel from Apple (I wrote it). It lets you disable some or all of the dialogs the AppleShare client puts up. Or, you can let them come up, but time out after a specified amount of time. AppleShareSetup is available on most major online services and from Apple's ftp server. >2) Is there anyway to change the default timeout time, it's >approximately 2 minutes in our LAN? There's really no good way to change that. The time-out is handled by the .XPP driver's ASP/AFP protocol stack and the ASP specification says the time-out for sessions is two minutes. I guess you could use PConfirmName to see if the server is still responding to directed NBP lookups and if it doesn't respond within a certain amount of time, you could kill the ASP session with ASPCloseSession. I wrote a Macintosh Tech Note that tells how to get the AFP/ASP session reference number a few years ago. You should be able to find it in the Network Tech Notes at <http://dev.info.apple.com/technotes/Archive/Main_archive.html>. This technique is rather rude though. >3) The initial mac needs to reconnect to the shutdown mac after >it restarts which we're assuming is almost right away. You can reconnect by either resolving an alias to the server, or by using the File Manager's PBVolumeMount function. You'll have to take care of that from your own code. - Jim Luther --------------------------- >From 'Digital Dave' Shields <digidave@best.com> Subject: Stuck in a bottleneck Date: Sun, 11 Feb 1996 21:56:16 -0800 Organization: Vanguard Vision Studios, San Francisco, CA I have created some special PICT files with data stored in each file's Pic Comment field. In order to parse the data, I have installed a CQDProc bottleneck procedure in my code. The procedure is being called fine. My problem is the bottleneck procedure needs to communicate with the rest of the code by setting application globals. The bottleneck procedure is a callBack routine, and I don't have access to application globals without setting up and restoring the A4 register (under Think C it's A4 not A5). Since the bottleneck procedure doesn't include a reference constant field as one of its arguments, I cannot pass the address of the application's A4 to the bottleneck proc in order to do this. Any suggestions? --Dave +++++++++++++++++++++++++++ >From monhacker@aol.com (MonHacker) Date: 12 Feb 1996 13:12:24 -0500 Organization: America Online, Inc. (1-800-827-6364) << Any suggestions? >> Have you considered making your own OS queue? Bob Boylan +++++++++++++++++++++++++++ >From jmunkki@beta.hut.fi (Juri Munkki) Date: 12 Feb 1996 20:06:14 GMT Organization: Helsinki University of Technology In article <311ED680.613A@best.com> digidave@best.com writes: >My problem is the bottleneck procedure needs to communicate with the >rest of the code by setting application globals. The bottleneck >procedure is a callBack routine, and I don't have access to application >globals without setting up and restoring the A4 register (under Think C >it's A4 not A5). Bottlenecks have full access to application globals. Unless you are writing a code resource instead of a full application, the register is A5 just like in all other environments. >Since the bottleneck procedure doesn't include a reference constant >field as one of its arguments, I cannot pass the address of the >application's A4 to the bottleneck proc in order to do this. If you need to do something like this, the usual procedure is to append a field to the structure that is passed to the callback. In this case you could add a field to the CGrafPort (allocate it yourself, of course) and set it to A5. Fortunately it is not needed in this case. -- Juri Munkki jmunkki@iki.fi Life is easy when polygons are cheap. http://www.iki.fi/jmunkki Windsurfing: Faster than the wind. +++++++++++++++++++++++++++ >From 'Digital Dave' Shields <digidave@best.com> Date: Mon, 12 Feb 1996 20:11:14 -0800 Organization: Vanguard Vision Studios, San Francisco, CA MonHacker wrote: > > Have you considered making your own OS queue? I thought a Bottleneck procedure was called at "interrupt time". Is this not true? If so, that would mean one could not move memory. In a message queue structure, you have to allocate an object on the heap and add it in...or is there another way to set up a queue for this purpose? --Dave +++++++++++++++++++++++++++ >From pottier@drakkar.ens.fr (Francois Pottier) Date: 13 Feb 1996 10:58:57 GMT Organization: Ecole Normale Superieure, Paris, France In article <31200F62.71D8@best.com>, 'Digital Dave' Shields <digidave@best.com> wrote: >I thought a Bottleneck procedure was called at "interrupt time". Is this >not true? Although Juri has already said it, I will reiterate to clear some misconceptions: if you are writing an application, your globals can be accessed (off the A5 register) without needing to do anything special in your bottleneck. Bottlenecks are not called at interrupt time; they are called by DrawPicture and they are free to move memory, write into global variables. I guess the only thing they can't do (unless you know what you're doing) is to make QuickDraw calls. -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ +++++++++++++++++++++++++++ >From jmunkki@beta.hut.fi (Juri Munkki) Date: 14 Feb 1996 00:39:51 GMT Organization: Helsinki University of Technology In article <31200F62.71D8@best.com> digidave@best.com writes: >MonHacker wrote: >> >> Have you considered making your own OS queue? > >I thought a Bottleneck procedure was called at "interrupt time". Is this >not true? It is not true. QD Bottlenecks are called from within QuickDraw. QuickDraw may not be called from within interrupts. Thus, QD bottlenecks may move memory and do just about anything you want. >If so, that would mean one could not move memory. In a message queue >structure, you have to allocate an object on the heap and add it in...or >is there another way to set up a queue for this purpose? OS Queues are useful because Enqueue and Dequeue disable interrupts during critical sections so that you can access the queues from within interrupts without having to worry about a non-interrupt level routine being in the middle of changing the queue structure. In this particular case, I don't see how they could be useful. The normal procedure is that the queue entry is something like a parameter block and the block is owned by the queue until it is no longer needed. (If you call PBRead asynchronously, the parameter block is reserved until the read completes.) If you need to enqueue stuff from an interrupt level, you have to preallocate the entries. The best way to do this is to allocate a chunk of memory at startup and then enqueue entries from this memory. When you need a block, you dequeue from the queue. When the block is released, you enqueue it back into your free queue. But, as I said, OS queues have very little to do with QD bottlenecks. -- Juri Munkki jmunkki@iki.fi Life is easy when polygons are cheap. http://www.iki.fi/jmunkki Windsurfing: Faster than the wind. +++++++++++++++++++++++++++ >From dbrosius@chesco.com (Dave M Brosius) Date: 17 Feb 1996 08:19:37 GMT Organization: Chester County Internet Services, Inc. In article <4fpqth$mu4@nef.ens.fr>, pottier@drakkar.ens.fr (Francois Pottier) wrote: > In article <31200F62.71D8@best.com>, > 'Digital Dave' Shields <digidave@best.com> wrote: > Bottlenecks are not called at interrupt time; they > are called by DrawPicture and they are free to move memory, write into > global variables. I guess the only thing they can't do (unless you know > what you're doing) is to make QuickDraw calls. You can however call the Stdxxxx forms of quickdraw calls. -- Please reply via email as well dave dbrosius@chesco.com --------------------------- >From mxmora@apple.com (Matthew Xavier Mora) Subject: USENET Macintosh Programming Awards (UMPA) Date: Fri, 16 Feb 1996 17:57:22 GMT Organization: MXM Designs Announcing The Second Annual USENET Macintosh Programming Awards UMPA 1996 It is now time to start nominating this years programmers. Below is the article I sent out to the c.s.m.p.* newsgroups to start the nomination process. Since I sent out that article Bare Bones Software and Metrowerks said that they would sponsor this years event. Cool! We have been getting a lot of prizes thanks to some evanglizing from Jordan Mattson. Thanks Jordan. So the list of prizes so far is: Every winner will get this stuff: - UMPA T -Shirt - UMPA Plaque. - $100.00 Cash Prize (Oooh!) - $100.00 APDA Gift Certificate (from Juan Bettaglio ) - A Self Paced Course from DU (from Jennifer Martin) - One years free membership in the Associates Plus or AMP program ( Or an extension if currently enrolled from Cindy Gallie) The things below will go to the winners of the ShareWare, Freeware, Support and Smart friend categories only since the Commercial winner has all this stuff anyway. - Lots o' Symantec Stuff (includes Mac C++ and Java tools) (from Will Iverson) t-shirts, option for any Symantec product NFR (e.g. a choice of C++ Win, ACT!, Norton, etc.). - Apprentice CD (From Paul Celestin ) - BBEdit and BBEdit T-shirts (From Rich Siegel) - Metrowerks Gold CD - QC from Devon Hubbard - Roaster the Java Development Environment from Natural Intelligence A big thanks to our sponsors! So send in your nominations! Matt - ----------------------------------------------------------- U M P A - ----------------------------------------------------------- It looks like its time for the Second Annual Usenet Macintosh Programming Awards (UMPA). For those of you that have never heard of this before, last year we created the UMPA awards to honor our peers in the Mac Programming world. Often a program itself will get awarded but the person(s) responsible for creating the product never get their due recognition for a job well done. This award is to honor those in the trenches fighting the good fight for the Macintosh. I would like to start the nomination process now and have it go until the end of March. (Prizes determined by the number of vendors willing to donate prizes) Here is a list of the categories. The five categories are: Outstanding Programming for a Commercial Product. Outstanding Programming for a Shareware Product. Outstanding Programming for a Freeware Product Outstanding Support of the Mac programming community. (usually from a non programmer) Official SmartFriend(tm) award for the most helpful c.s.m.p.* net citizen. Here is a list of the current nominees (Remember we are nominating the programmers not the product so please include the name of the programmer(s)): Outstanding Programming for a Commercial Product: 1. Rich Siegel for BBEdit 2. Jordan Zimmerman for QuickView/MPTA 3. OneClick (WestCode Software) Outstanding Programming for a Shareware Product: 1. Peter Lewis for Net Presenz Outstanding Programming for a Freeware Product: 1. Michael Hecht for ResCompare 2. Steve Dagley, Richard Reynolds, and Co. for FreePPP. 3. Lindsay Davies and Carles Bellver for HTML tools for BBEdit Outstanding Support of the Mac programming community: 1. The folks at MetroWerks 2. Neil Ticktin of MacTech Magazine Official SmartFriend(tm) award : 1. Jon Pugh, for many of his insights on AppleScript The list of final nominees is chosen by the number times that programmer was nominated. So if you want your favorite programmer to make the nomination cut, Send in his/her name. Since this award is supposed to be recognition from our peers, You will need to answer a Macintosh programming question to have a valid nomination. The first question is: What is the recommended sleep value for WaitNextEvent for a foreground Application. :-) So send me your nominations <mailto:mxmora@mxmdesigns.com> with what you "think" is the correct answer to the above question and I will keep updating the nomination list. I will set up a web page for this when ever I can remember my password to my shell account. If you would like to donate prizes to this cause, please send me email <mailto:mxmora@mxmdesigns.com>. Last year we collected 5 prizes for each category. This year I think we should just collect 4 prizes since the "Outstanding Programming for a Commercial Product" winner already had all the stuff we collected last year. The award,t-shirt and plaque cash and other goodies is probably honor enough. Thanks for listening and good luck to the nominees! Xavier -- Matthew Xavier Mora Developer Technical Support Apple Computer, Inc. mxmora@apple.com --------------------------- >From ericg@teleport.com (MystryMan) Subject: [Q] NURBs and lighting Date: 30 Jan 1996 14:17:58 -0800 Organization: Teleport - Portland's Public Access (503) 220-1016 Can anyone explain why when my camera is at ( 0 0 200 ) looking to ( 0 0 0 ) and my pointlight is at ( 0 0 -200 ), I see half the sphere colored in RED? It seems to me that since the light on the opposite side of the sphere (as compared to the camera), the side of the sphere I am viewing through the camera should be black (I have no ambient light). What am I missing? It's probably something obvious, but I don't see it. Since I know other people are interested in seeing an example of a NURB sphere using QD3D, I am posting the entire metafile (it's small). 3DMetafile ( 1 0 Normal tableofcontents0> ) viewhints2: Container ( ViewHints ( ) interactiverenderer3: Container ( InteractiveRenderer ( ) InteractiveDoubleBufferBypass ( True ) ) viewangleaspectcamera4: Container ( ViewAngleAspectCamera ( 0.8726646 1 ) CameraPlacement ( 0 0 200 # location 0 0 0 # point of interest 0 1 0 # up vector ) CameraRange ( 0.1 500 ) CameraViewPort ( -1 1 2 2 ) ) pointlight5: Container ( PointLight ( 0 0 -200 # location 0 0 0 # attenuation False # castsShadows ) LightData ( True # isOn 1 # brightness 1 0 0 # color ) ) attributeset6: Container ( AttributeSet ( ) AmbientCoefficient ( 1 ) DiffuseColor ( 0.5 0.5 0.5 ) SpecularColor ( 0.5 0.5 0.5 ) SpecularControl ( 4 ) TransparencyColor ( 1 1 1 ) ) ImageClearColor ( 0 0 1 0 ) ImageDimensions ( 300 300 ) ) phongillumination7: PhongIllumination ( ) interpolationstyle8: InterpolationStyle ( Pixel ) backfacingstyle9: BackfacingStyle ( Both ) fillstyle10: FillStyle ( Filled ) ordereddisplaygroup11: BeginGroup ( OrderedDisplayGroup ( ) ) scale12: Scale ( 75 75 75 ) nurbpatch13: Container ( NURBPatch ( 3 3 # uOrder, vOrder 5 9 # numRows, numColumns 0 -1 0 1 0 -0.707107 0 0.707107 0 -1 0 1 0 -0.707107 0 0.707107 0 -1 0 1 0 -0.707107 0 0.707107 0 -1 0 1 0 -0.707107 0 0.707107 0 -1 0 1 0.707107 -0.707107 0 0.707107 0.5 -0.5 0.5 0.5 0 -0.707107 0.707107 0.707107 -0.5 -0.5 0.5 0.5 -0.707107 -0.707107 0 0.707107 -0.5 -0.5 -0.5 0.5 0 -0.707107 -0.707107 0.707107 0.5 -0.5 -0.5 0.5 0.707107 -0.707107 0 0.707107 1 0 0 1 0.707107 0 0.707107 0.707107 0 0 1 1 -0.707107 0 0.707107 0.707107 -1 0 0 1 -0.707107 0 -0.707107 0.707107 0 0 -1 1 0.707107 0 -0.707107 0.707107 1 0 0 1 0.707107 0.707107 0 0.707107 0.5 0.5 0.5 0.5 0 0.707107 0.707107 0.707107 -0.5 0.5 0.5 0.5 -0.707107 0.707107 0 0.707107 -0.5 0.5 -0.5 0.5 0 0.707107 -0.707107 0.707107 0.5 0.5 -0.5 0.5 0.707107 0.707107 0 0.707107 0 1 0 1 0 0.707107 0 0.707107 0 1 0 1 0 0.707107 0 0.707107 0 1 0 1 0 0.707107 0 0.707107 0 1 0 1 0 0.707107 0 0.707107 0 1 0 1 0 0 0 1 1 2 2 3 3 4 4 4 # uKnots 0 0 0 1 1 2 2 2 # vKnots ) attributeset14: Container ( AttributeSet ( ) AmbientCoefficient ( 1 ) DiffuseColor ( 1 1 1 ) SpecularColor ( 1 1 1 ) SpecularControl ( 4 ) ) ) EndGroup ( ) ===Eric Gorr=================ericg@egi.com=================aka MystryMan=== _____ * http://www.teleport.com/~ericg * |\ /| * Invincibility is in oneself, vulnerability is in the opponent | O | * Therefore the considerations of the intelligent always include both |/_\| benefit and harm (Sun Tzu) #include <standard.disclaimer> =====Insults, like violence, are the last resort of the incompetent...===== +++++++++++++++++++++++++++ >From ericg@teleport.com (MystryMan) Date: 31 Jan 1996 17:56:53 -0800 Organization: Teleport - Portland's Public Access (503) 220-1016 I have been able to get the correct side of the sphere lighted...but I don't understand *why*. By changing the backfacing style to kQ3BackfacingStyleFlip, the correct part of the sphere is now lit. When my object is not transparent, etc., why would the backfacing style cause the opposite part of the sphere (in relation to the location of the light) to be lit? I find this very odd. ===Eric Gorr=================ericg@egi.com=================aka MystryMan=== _____ * http://www.teleport.com/~ericg * |\ /| * Invincibility is in oneself, vulnerability is in the opponent | O | * Therefore the considerations of the intelligent always include both |/_\| benefit and harm (Sun Tzu) #include <standard.disclaimer> =====Insults, like violence, are the last resort of the incompetent...===== +++++++++++++++++++++++++++ >From Pablo Fernicola <pff@apple.com> Date: Sun, 4 Feb 1996 21:51:33 GMT Organization: Apple Computer, Inc. In article <4ep6l6$1d9@kelly.teleport.com> MystryMan, ericg@teleport.com writes: >I have been able to get the correct side of the sphere lighted...but I >don't understand *why*. > >By changing the backfacing style to kQ3BackfacingStyleFlip, the correct >part of the sphere is now lit. Sounds like your patch is inside out. -Pablo >Pablo Fernicola- pff@apple.com -QuickDraw 3D Tech Lead - --- This posting represents my personal opinions.----- - --- I do not represent/speak for my employer. ----- +++++++++++++++++++++++++++ >From vanessa@io.org (Vanessa Williams) Date: Thu, 08 Feb 1996 15:45:29 -0500 Organization: Tessera Solutions In article <1996Feb4.215133.22065@gallant.apple.com>, Pablo Fernicola <pff@apple.com> wrote: > In article <4ep6l6$1d9@kelly.teleport.com> MystryMan, ericg@teleport.com > writes: > > >By changing the backfacing style to kQ3BackfacingStyleFlip, the correct > >part of the sphere is now lit. > > Sounds like your patch is inside out. What would one have to do wrong in order to create an inside-out patch? > -Pablo > >Pablo Fernicola- pff@apple.com -QuickDraw 3D Tech Lead > ----- This posting represents my personal opinions.----- > ----- I do not represent/speak for my employer. ----- +++++++++++++++++++++++++++ >From ericg@teleport.com (MystryMan) Date: 9 Feb 1996 11:46:27 -0800 Organization: Teleport - Portland's Public Access (503) 220-1016 In article <1996Feb4.215133.22065@gallant.apple.com>, Pablo Fernicola <pff@apple.com> wrote: >In article <4ep6l6$1d9@kelly.teleport.com> MystryMan, ericg@teleport.com >writes: >>I have been able to get the correct side of the sphere lighted...but I >>don't understand *why*. >> >>By changing the backfacing style to kQ3BackfacingStyleFlip, the correct >>part of the sphere is now lit. > >Sounds like your patch is inside out. Why should this matter? Why would something seem to be lighted when the light source is on the opposite side? Or is this just the way lighting works? ===Eric Gorr=================ericg@egi.com=================aka MystryMan=== _____ * http://www.teleport.com/~ericg * |\ /| * Invincibility is in oneself, vulnerability is in the opponent | O | * Therefore the considerations of the intelligent always include both |/_\| benefit and harm (Sun Tzu) #include <standard.disclaimer> =====Insults, like violence, are the last resort of the incompetent...===== +++++++++++++++++++++++++++ >From Pablo Fernicola <pff@apple.com> Date: Sat, 10 Feb 1996 01:53:47 GMT Organization: Apple Computer, Inc. In article <vanessa-0802961545290001@ts44-03.tor.inforamp.net> Vanessa Williams, vanessa@io.org writes: >What would one have to do wrong in order to create an inside-out patch? Here is the answer from Philip Schneider, our NURB specialist: The best way to explain how a NURB patch is properly "formatted" is to show an example of one in "canonical" position. The various fields of the TQ3NURBPatchData data structure must be set up correctly with respect to this, in terms of what the various fields are, how many knots one has, and the ordering of the control points. Here's the data structure: typedef struct TQ3NURBPatchData { unsigned long uOrder; unsigned long vOrder; unsigned long numRows; unsigned long numColumns; TQ3RationalPoint4D *controlPoints; float *uKnots; float *vKnots; unsigned long numTrimLoops; TQ3NURBPatchTrimLoopData *trimLoops; TQ3AttributeSet patchAttributeSet; } TQ3NURBPatchData; Consider a bicubic NURB patch that is facing you, and has 5 control points in the U direction, and 4 control points in the V direction. Conceptually, a NURB patch's control points are a 2-dimensional array of points; of course, we have to represent this as a list of points in C when we pass them into the NURB drawing routine. So, one has to make sure that the points are listed in the order in which QD3D expectsthem. That order is as follows: 1. The first control point is at the lower left corner. 2. The bottom row, corresponding to the U parameter direction, is listed from left to right. 3. Then, the next-up-from-the-bottom row is listed, and so on. Here's some C specifying such a NURB patch: static float *uKnots = { 0, 1, 2, 3, 4, 5, 6, 7, 8 }; static float *vKnots = { 0, 1, 2, 3, 4, 5, 6 ,7 }; static TQ3NURBPatchData *patchData = { 4, /* uOrder */ 4, /* vOrder */ 4, /* numRows */ 5 /* numColumns cp, /* control points uKnots, /* u knots vKnots, /* v knots 0, /* numTrimLoops NULL, /* trimLoops */ NULL /* patchAttributeSet */ }; I'll not list the control points' values, but rather show how they should be laid out to get the correct effect: 15--16--17--18--19 | | | | | 10--11--12--13--14 | | | | | ^ 5---6---7---8---9 | | | | | | V 0---1---2---3---4 U-> A failure to conform to this orientation will result either in the NURB patch appearing to be "backwards"; failure to conform to the proper relationship between rows/columns, uKnots/vKnots, and/or uOrder/vOrder can result in bus errors due to the system looking for more knots than you specified, wrong number of control points, etc. etc. - ---- A side effect of the patch being backwards or inside out is that its vertex normals (used for lighting calculations) willl be pointing in the wrong direction. >Pablo Fernicola- pff@apple.com -QuickDraw 3D Tech Lead - --- This posting represents my personal opinions.----- - --- I do not represent/speak for my employer. ----- +++++++++++++++++++++++++++ >From jstratmn@inlink.com (Joe Stratmann) Date: Thu, 15 Feb 1996 05:52:14 GMT Organization: inlink >Why should this matter? Why would something seem to be lighted when the light >source is on the opposite side? Or is this just the way lighting works? Can anyone tell me if Quickdraw 3D will support double-sided faces? Thanks Joe +++++++++++++++++++++++++++ >From johnb@hk.super.net (John W. Blackburne) Date: Thu, 15 Feb 1996 22:53:30 +0800 Organization: Tempest In article <4fuh4c$aun@news1.inlink.com>, jstratmn@inlink.com (Joe Stratmann) wrote: :>Why should this matter? Why would something seem to be lighted when the light :>source is on the opposite side? Or is this just the way lighting works? : : :Can anyone tell me if Quickdraw 3D will support double-sided faces? By default it will light both sides as if they were the same material, i.e. with same colour, reflectiveness, etc. But most shapes have a front and a back, and you can optionally turn off backfacing so it only draws the front sides, good for polyhedra which will only be looked at from the outside. When I did this with my code it gave it an appreciable speed boost with SW only QD3D. I also discovered where I'd got the front and backs of my polygons mixed up. As for having a surface with opposite sides with different properties, I don't know a way to do this. For the one place where I wanted this I just created two squares and put them back to back. With backfacing off it's probably little extra work for the drawing engine to do this, and it looks just fine. John -- John Blackburne, johnb@tempest.net.hk Programmer Asia, Inc. Online: http://www.asia-inc.com Technology consultant and trainer: http://www.hk.super.net/~johnb +++++++++++++++++++++++++++ >From jstratmn@inlink.com (Joe Stratmann) Date: Fri, 16 Feb 1996 18:02:53 GMT Organization: inlink johnb@hk.super.net (John W. Blackburne) wrote: >By default it will light both sides as if they were the same material, >i.e. with same colour, reflectiveness, etc. But most shapes have a front >and a back, and you can optionally turn off backfacing so it only draws >the front sides, good for polyhedra which will only be looked at from the >outside. When I did this with my code it gave it an appreciable speed >boost with SW only QD3D. I also discovered where I'd got the front and >backs of my polygons mixed up. >As for having a surface with opposite sides with different properties, I >don't know a way to do this. For the one place where I wanted this I just >created two squares and put them back to back. With backfacing off it's >probably little extra work for the drawing engine to do this, and it looks >just fine. Thanks for replying to my mail John. Ok, so QD3D does support dual-faced polygons (don't need to have a different surface on either side). Now, assume you don't want backfacing on. So you have to make sure all faces are in the proper direction. Is it possible for the program to figure this out or not? Also, how *do* you find out which way a polygon is facing? Oh, one more (sorry for being so inquisitive) - what does "normalize" mean and how do you do it? Thanks again Joe +++++++++++++++++++++++++++ >From johnb@hk.super.net (John W. Blackburne) Date: Sat, 17 Feb 1996 18:44:00 +0800 Organization: Tempest In article <4g2ga9$l8a@news1.inlink.com>, jstratmn@inlink.com (Joe Stratmann) wrote: :johnb@hk.super.net (John W. Blackburne) wrote: : :>By default it will light both sides as if they were the same material, :>i.e. with same colour, reflectiveness, etc. But most shapes have a front :>and a back, and you can optionally turn off backfacing so it only draws :>the front sides, good for polyhedra which will only be looked at from the :>outside. When I did this with my code it gave it an appreciable speed :>boost with SW only QD3D. I also discovered where I'd got the front and :>backs of my polygons mixed up. : :>As for having a surface with opposite sides with different properties, I :>don't know a way to do this. For the one place where I wanted this I just :>created two squares and put them back to back. With backfacing off it's :>probably little extra work for the drawing engine to do this, and it looks :>just fine. : :Thanks for replying to my mail John. Ok, so QD3D does support :dual-faced polygons (don't need to have a different surface on either :side). : :Now, assume you don't want backfacing on. So you have to make sure :all faces are in the proper direction. Is it possible for the program :to figure this out or not? The program figures it out by way of the parameters you specify to create an object, e.g. the order in which vertices are given when specifying a polygon, or the vectors are given when specifying a cube. The problem is the mathematics of this is IMHO pretty tricky - it's complex to express and even more complex to apply. Rather than sit down and mathematically work out the orientation of the polygions in meshes I've created I've found it easier to just throw them all into the mesh, turn off back-facing, see what it looks like, then reverse those (by reversing the order of the vertices given to Q3Mesh_FaceNew) which looked wrong. :Also, how *do* you find out which way a polygon is facing? See above. If you want the maths it is different for different geometric objects but can all be found in the QD3D docs. :Oh, one more (sorry for being so inquisitive) - what does "normalize" :mean and how do you do it? A 'normalized' vector (which I'm more used to calling a unit vector) is one with unit length, e.g. if the vector is [x, y, z] then x^2 + y^2 + z^2 = 1. To 'normalize' a vector is to turn it into such a vector, by finding a vector in the same direction but of unit length. Unit vectors are useful for certain vector calcualtions, and are required by QD3D for setting up certain cameras. Thnkfully you never need to normalize a vector in QD3D, as it provides a function (Q3Vector3D_Normalize) to do it for you. John -- John Blackburne, johnb@tempest.net.hk Programmer Asia, Inc. Online: http://www.asia-inc.com Technology consultant and trainer: http://www.hk.super.net/~johnb --------------------------- >From joost@sirius.com (Joost Romeu) Subject: pragma once vs #ifndef Date: 8 Feb 1996 17:32:36 GMT Organization: sirius.com I understand that: #pragma once // placed at the top of a header file is a preprocessor directive that tells the compiler not to include the current header file being compiled (ie. the one that contains it) if that header has already been included in the same src file I also understand that by placing - at the top of the header file, <FILENAME>.h the statements: > #ifndef_<FILENAME>_H > #define_<FILENAME>_H >... >#endif // end of header file Says, in effect, if filename.h hasn't been defined, then define it, otherwise skip it... ?1: Are these two preprocessor statements equivalent? ?2: Which one is better to use for the duplicate header problem? ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit copy/compare?) Thanks -- please also reply as email... +++++++++++++++++++++++++++ >From dbrosius@chesco.com (Dave M Brosius) Date: 10 Feb 1996 06:45:30 GMT Organization: Chester County Internet Services, Inc. In article <joost-0802960933550001@ppp072-sf2.sirius.com>, joost@sirius.com (Joost Romeu) wrote: > I understand that: > > #pragma once // placed at the top of a header file > > is a preprocessor directive that tells the compiler not to include the > current header file being compiled (ie. the one that contains it) if that > header has already been included in the same src file > > I also understand that by placing - at the top of the header file, > <FILENAME>.h the statements: > > > #ifndef_<FILENAME>_H > > #define_<FILENAME>_H > >... > >#endif // end of header file > > Says, in effect, if filename.h hasn't been defined, then define it, > otherwise skip it... > > ?1: Are these two preprocessor statements equivalent? > > ?2: Which one is better to use for the duplicate header problem? > > ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit > copy/compare?) > > Thanks > > -- > please also reply as email... #ifndef_<FILENAME>_H #define_<FILENAME>_H is guaranteed to work with any compiler. Why #pragma once may or may not.... That alone is enough for me to choose the #ifndef version -- dave dbrosius@chesco.com +++++++++++++++++++++++++++ >From gurgle@apple.com (Pete Gontier) Date: Tue, 13 Feb 1996 15:09:06 -0800 Organization: Apple Computer, Inc. In article <joost-0802960933550001@ppp072-sf2.sirius.com>, joost@sirius.com (Joost Romeu) wrote: > ?1: Are these two preprocessor statements equivalent? > ?2: Which one is better to use for the duplicate header problem? > ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit > copy/compare?) For more information than you ever wanted, post these questions to comp.lang.c. The answers may even be in the FAQ. But briefly, the #pragma is theoretically faster because it tells the compiler to subsequently avoid looking for the file or reading it. The #ifdef trick still allows for the possibility that the compiler will go look for the file and read it. (The search often takes longer than the read, of course.) Some compilers are clever and recognize the #ifdef trick and treat it the #pragma. But since this isn't really conformant behavior (you might #undef the symbol specifically to get the duplication on the second #include), there's generally a compiler switch to control it. Another option you have is to shield your #include statements: #ifndef __WINDOWS__ # include <Windows.h> #endif I do this all the time for the Toolbox headers because they aren't smart enough to use the #pragma. For my own headers I use the #pragma. - --------- Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support work mail <mailto:gurgle@apple.com> personal mail <mailto:gurgle@ccnet.com> personal web <http://www.ccnet.com/~gurgle> work web <http://dev.info.apple.com/dts.html> +++++++++++++++++++++++++++ >From rdwells@mmm.com (Richard Wells) Date: Fri, 16 Feb 1996 17:17:40 -0600 Organization: 3M Company Pete Gontier wrote: > > In article <joost-0802960933550001@ppp072-sf2.sirius.com>, > joost@sirius.com (Joost Romeu) wrote: > > > ?1: Are these two preprocessor statements equivalent? > > ?2: Which one is better to use for the duplicate header problem? > > ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit > > copy/compare?) > > For more information than you ever wanted, post these questions to > comp.lang.c. The answers may even be in the FAQ. I doubt that it's in the FAQ, since "#pragma once" is not sufficiently universal. It is common in the Mac world, but I don't know of any PC or Unix compilers that support it. So if your code is intended to be portable, I wouldn't use it. Since most of what I write does have to be portable, I stick to the #ifndef method. Opinions expressed herein are my own and may not represent those of 3M. +++++++++++++++++++++++++++ >From clay@herky.cs.uiowa.edu (Matthew Clay) Date: 17 Feb 1996 05:13:00 GMT Organization: University of Iowa, Iowa City, IA, USA >From article <31251094.4220@mmm.com>, by rdwells@mmm.com (Richard Wells): > Pete Gontier wrote: >> >> In article <joost-0802960933550001@ppp072-sf2.sirius.com>, >> joost@sirius.com (Joost Romeu) wrote: >> >> > ?1: Are these two preprocessor statements equivalent? >> > ?2: Which one is better to use for the duplicate header problem? >> > ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit >> > copy/compare?) >> >> For more information than you ever wanted, post these questions to >> comp.lang.c. The answers may even be in the FAQ. > > I doubt that it's in the FAQ, since "#pragma once" is not sufficiently > universal. It is common in the Mac world, but I don't know of any PC > or Unix compilers that support it. > > So if your code is intended to be portable, I wouldn't use it. Since > most of what I write does have to be portable, I stick to the #ifndef > method. This eternal debate was recently revisited in comp.lang.c++.moderated, and I think the strongest arguments were for #ifndef...#endif. For the original questions, 1) They're pretty close to equivalent if available. The advantages of #pragma once is that it doesn't introduce a new symbol name, and that at least initially, it allowed faster tests. Nothing however prevents a compiler from recognizing the common #ifndef...#endif pattern and treating it similarly. 2) Given that #pragma means "preprocessor/compiler hint", #pragma once is not a terribly portable construct, though many a book suggests otherwise. In terms of copies sold, I would assume Microsoft Visual C++ is the world's most popular compiler and it doesn't understand #pragma once. 3) I'm not sure I understand bit comparison in this context, but note it's probably unwise to have several header files with the same name in the same project or search tree. And it's not in the faq but is definitely is frequently asked. -mc +++++++++++++++++++++++++++ >From jps@tfs.com (Jeff Stearns) Date: 15 Feb 1996 21:48:04 GMT Organization: TRW Financial Systems In article <joost-0802960933550001@ppp072-sf2.sirius.com>, Joost Romeu <joost@sirius.com> compares #pragma once to #ifndef/#define/#endif. > ?1: Are these two preprocessor statements equivalent? > > ?2: Which one is better to use for the duplicate header problem? > > ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit copy/compare?) They usually have the same effect. #pragma once is probably more efficient because the compiler can keep a list of the names of files which have already been #included. When it encounters a #include somefile directive, it can search the list and do nothing if it discovers that somefile is already on the list. (It probably compares only filenames, not file contents.) This is faster than searching for the file, opening it, and parsing it for #ifndef/#endif pairs. I have seen failures with both methods on various platforms: Symantec C version 6 includes the wrong file occasionally if there is a header file in the source tree which has the same name as a header in the compiler tree (for example, if there is a local "errors.h" and an <Errors.h>.) and the "Include headers only once" option is selected. Sun's SPARCworks C compiler also makes mistakes in the way that it caches #include files, reading the wrong one on rare occasions. Both bugs stem from the compiler's attempt to speed things up by keeping lists of #include files already visited. On the whole, I've experienced fewer bugs using the #ifndef/#define/#endif method. --------------------------- End of C.S.M.P. Digest **********************